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Int  roduct i on 

The  ourpose  of  this  reoort  is  to  describe  a  methodology 
for  the  soecificaton  and  development  of  portable  software 
env i r ornient s  for  limited  resource  machines.  The  ultimate 
goal  of  this  work  is  to  be  able  to  build  a  portable  software 
development  environment  for  development  on  and  for  limited 
resource  machines.  A  limited  resource  develooment  system  is 
a  single  user  system  that  includes  a  processor*  memory*  disk 
storage*  disolay*  keyboard*  and  list  device.  The  target 
machine  for  develooment  might  be  a  dedicated  processor 
system  such  as  in  a  smart  device  such  as  a  robot*  or  process 
control  device*  or  it  may  be  an  application  on  the 
development  system. 

The  soecific  oroblem  addressed  here  is  the  develooment 
of  a  methodology  for  specifying  resources*  both  physical 
resources  and  oroblem  solving  (software)*  in  an 
implementation  independent  manner.  This  methodology  can 
then  be  used  to  specify  successive  layers  of  resource 
abstraction*  beginning  with  the  ohysical  resources  at  the 
lowest  level  and  endinq  with  oroblem  solvinq  abstractions  at 
the  highest  level.  To  achieve  this  goal  we  need  a 
conceotual  framework  that  has  the  following  features. 

It  must  oe  presentable  in  a  clear  and  precise  form. 

It  must  orovide  a  comolete  and  rigorous  theory  of 

abstract  soec i f i c a t i on 

It  must  include  a  oractical  theory  of  implementation 


A  number  of  people  have  worked  on  the  related  oroblem 
of  specifications  of  abstract  data  tyoes.  The  focus  of  this 
report  is  the  application  of  similar  techniques  to  the 
s oe c i f i c a t i on  of  physical  resources. 

To  further  clarify  my  objectives  here*  I  wish  to 
briefly  describe  some  of  the  historical  background  leadinq 
uo  to  the  current  work. 
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Tradi  t  iona  1  1  y,  software  envi  ronn'ents  have  developed 
around  a  oody  of  hardware  and  to  a  certain  extent  reflect 
this  heritage.  Such  systems  of  software  tend  to  develoo 
into  ’closed  systems’  of  software*  with  very  little 
possibility  of  movement  between  systems.  Even  though  hiah 
level  abstractions  provided  oy  high  level  languages  provide 
some  measure  of  software  standardization  and  Portability* 
they  tend  to  create  closed  systems  at  a  very  high  level*  and 
thus  their  portability  is  limited  because  to  oort  such  a 
system*  all  the  layers  of  software  below  them  must  be 
ported.  Moreover*  oecause  of  the  problems  in  specifying  the 
semantics  of  high  level  constructs  of  different  languages 
through  any  consistent  theory*  it  has  oroven  difficult  to 
translate  programs  in  one  1 anguaae  to  another.  These 
factors  and  the  labor  intensive  nature  of  systems  software 
development  have  combined  to  create  closed  systems. 

The  oroblem  of  creating  portable  software  achieved 
greater  significance  when  our  ability  to  design  and  create 
new  orocessors  accelerated.  Traditionally*  only  a  few 
companies  have  existed  to  produce  the  hardware  environments 
around  which  software  has  evolved.  With  the  development  of 
microprocessors  and  the  microcomputer  industry*  the  number 
of  companies  producing  computers  proliferated*  and  at  least 
initially*  no  one  computer  manufacturer  predominated.  At 
the  same  time  these  small  companies  did  not  have  the 
resources  to  develoo  an  extensive  body  of  software  for  their 
particular  environments*  particularly  things  such  as  high 
level  language  compilers.  Thus  a  new  set  of  conditions 
surrounding  the  design  and  development  of  software  occurred. 
The  result  has  been  that  standardization  and  abstraction 
occurred  at  levels  above  the  hardware*  but  below  the  high 
level  languages.  Examoles  of  this  are  CP/M,  the  P-system* 
and  *  C ’  and  the  *  C ’  runtime  system.  These  systems  are  a 
software  abstraction  of  physical  resources.  From  the 
historical  perspective*  this  is  one  of  the  more  interesting 
concepts  that  has  arisen  from  the  development  of 
mi c rocomput  ers. 

For  some  time*  it  has  been  recognized  that  the 
ooerating  system  represents  an  abstraction  of  the  hardware 
system  that  sjpports  the  layers  of  software  built  over  it* 
that  is*  an  operationg  system  is  an  abstraction  of  the 
physical  resources  of  a  system.  Traditionally  the  ooerating 
system  orovides  a  standardized  orogrammatic  interface  to  the 
secondary  memory  resources*  primary  memory  resources* 
processsors*  and  i /o  resources.The  most  recent  personal 
computing  systems  go  a  step  beyond  the  traditional  operating 
system  by  including  more  soohisticated  abstractions  of  the 
consol e  di sol  ay. 

The  oroblems  that  must  be  faced  in  trying  to  specify 
the  oroperties  of  a  real  or  aostract  physical  resource  are 
similar  to  the  problems  faced  by  linguists  who  try  to 
soecify  the  semantics  of  language  constructs.  It  is 
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difficult  to  develop  abstract  models  that  are  Dree i se» 
caoture  the  essential  features  of  somethinq  real »  yet  do  not 
ooscure  and  comolicate  our  ability  to  work  with  what  is 
real.  On  the  other  hand;  if  we  are  able  to  successfully 
caoture  the  essential  features  of  somethinq  we  know 
intuitively;  the  abstract  model  can  become  a  tool  that 
enables  us  to  sharoen  our  intuition;  and  increase  our 
understanding.  Unless  we  can  develoo  abstract  models  that 
allow  us  to  clothe  our  intuitive  notions  with  orecision;  we 
will  remain  at  an  imoasse  in  our  ability  to  know  which  of 
these  ideas  are  imoortant  and  which  are  not. 

In  the  following  section  we  will  outline  the  main 
elements  of  a  conceotual  system  develooed  for  this  ouroose. 
In  the  later  sections;  this  conceotual  system  is  made 
precise  and  illustrated  in  some  detail. 
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1  .0 

Conceptual  Fools 

There  are  a  number  of  features  of  the  oroblem  of 
aostract  soe c i f i c at i on  that  naturally  lead  us  to  draw  on 
mathematical  discioline.  The  methodology  we  use  must  be 
reoresentation  independent.  The  methodolgy  must  give  us  a 
method  of  proving  the  correctness  of  our  assertions  about 
formal  specifications  and  their  implementations.  We  must  be 
able  to  combine  and  compose  SDec i f i c at i ons .  The  methodology 
we  use  should  encourage  a  discioline  of  care  and  precision. 
At  the  same  time  we  should  attempt  to  avoid  unnecessary 
aostraction  or  concepts  that  do  not  directly  improve  the 
correct  use  of  the  methodology. 

Most  of  the  concepts  that  we  use  here  were  developed  to 
soecifiy  the  semantics  of  high  level  language  constructs# 
particularly#  the  specification  of  abstract  data  types. 
Since  the  specification  of  a  Portable  programmatic  interface 
has  its  origins  in  this  work#  and  since  these  concepts  are 
more  readily  understood  in  its  early  form#  we  will  begin 
with  an  informal  treatment  of  aostract  data  types. 


1  .  1 

Abstract  Data  Tyoes 

In  their  most  common  usages#  abstract  data  tyoes  are 
simply  proolem  solving  resources.  Some  astract  data  types# 
for  example  a  stack,  are  also  abstractions  of  physical 
resources.  Our  ouroose  is  to  develop  a  theory  of 
specification  that  can  be  used  to  describe  either  oroblem 
solving  (software)  resources  or  physical  resources.  To  do 
this#  we  use  a  theory  of  abstract  data  tyoes  that  has  been 
developing  over  a  number  of  years#  and  has  involved  a  number 
of  different  researchers.  The  primary  references  to  this 
work  can  be  found  in  Goguen  (1978)  and  Guttag  (19781. 

One  of  the  simplest  and  most  common  data  types  in 
mathematics  and  computer  science  is  boolean.  de  will  use 
this  data  tyoe  to  introduce  our  general  methods. 

Note  first  that  a  data  type  consists  of  more  than  the 
values  of  the  tyoe.  The  tyoe  is  a  comoosite  of  the  values 
and  the  operators  used  with  the  type.  In  traditional  usage# 
the  set  of  values  denotes  the  data  tyoe#  when  in  fact#  the 
aggregate  of  operations  and  values  denotes  the  tyoe.  There 
is  a  similar  misconceotion  of  the  function  concept  in 
mathematics.  Often  a  function  is  denoted  by  just  its  rule# 
when  in  fact  it  is  an  aggregate  of  domain#  codomain#  and 
rule. 
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For  the  ooolean  tyoe»  there  are  two  values  used/  which 
may  be  denoted  by  T  and  F  and  several  fundamental  operators 
such  as  1  "• 1  (logical  neqat  i  on)  »  '&'  (logical  conjunction) 
and  '!'  (logical  disjunction).  Finally/  there  are  relations 
that  must  hold  for  these  operators  as  given  by  the 
traditional  truth  tables: 


X 

r 

X 

X  Y 

!  &(X,Y) 

X 

y  : 

! (X, Y) 

T  !  F 

T  T 

!  T 

T 

t  : 

T 

F  !  T 

T  F 

!  F 

T 

F  ! 

T 

F  T 

5  F 

F 

T  1 

T 

F  F 

:  f 

F 

F  ! 

F 

With 

the  above 

definitions 

we  are  able 

t  0 

est  abl i sh 

truth 

of  other 

relations: 

The  idemootent  law 

for  negation 

The  associative  law  for  conjunction 


The  commutative  law  for  conjunction 

The  distributive  law  for  conjunction  and  disjunction 
The  De^organ  1 aws 

Obviously/  there  are  other  realizations  of  the  data 
type  that  we  normally  call  the  boolean  tyoe.  The  symbols 
used  for  the  data  values  may  oe  (0/l>/  the  ooerators  may  be 
given  different  notations/  etc.  The  fundamental  operators 
may  also  oe  different.  For  example/  the  fundamental 
operators  may  be  negation  and  implication.  It  is  generally 
understood  that  this  set  of  ooerators  defines  the  'same 
tyoe'.  Also/  it  is  clear  that  this  data  type  admits  many 
other  operators/  exclusive  disjunction/  for  example.  It  is 
clearly  difficult  to  capture  the  essence  of  a  tyoe  itself/ 
independently  of  a  particular  realization  of  it.  This  is 
one  of  the  problems  that  a  theory  of  abstract  specification 
must  solve. 

The  things  that  are  useful  about  a  data  tyoe  are  not 
just  the  values  of  the  tyoe  and  the  ooerators  of  the  type/ 
but  the  expressions  we  can  build  from  values  and  operators. 
We  use  expressions  to  calculate  with  boolean  values/  so  we 
need  to  'evaluate'  expressions  and  to  determine  if  two 
expressions  are  'equal'/  etc.  Expressions  are  built  from 
values  and  operators  by  abiding  by  the  domain  constraints  of 
the  operators/  and  using  comoosition  of  operators.  For 
example/  all  the  following  are  obviously  correctly  formed 
expressions/  assuming  a  prefix  form  for  the  ooerators. 


(m(&(T,F) ) 
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&(T,-<(&(F,MT)  ) ) 

We  also  font  expressions  with  'free  variables': 

! (i(x)*&(T,y)) 

where  of  course  x  and  v  are  the  'free'  variables.  Often  we 
want  to  determine  if  two  expressions  are  'formally  equal'. 
In  particular  we  have  reason  to  believe  that  every 
expression  without  free  variaoles  is  eaual  to  either  T  or  F. 
Or  we  may  have  reason  to  believe  that  we  can  'prove'  that 
the  expression  m  (  &  (  x  *  y  ) )  equals  J  (m  (  x  ) *  (  y  ) )  .  In  general  » 

whenever  we  create  and  use  a  'data  type'*  we  are  potentially 
interested  in  the  set  of  all  expressions  involving  values  of 
the  type  or  free  variables  on  the  type.  These  objects  are 
the  abstract  representatives  of  the  things  in  the  real  world 
modeled  by  the  data  type.  In  fact*  Hoffman  and  O'Donnell 
U982]  have  recently  expressed  the  view  that  much  of 
computing  involves  no  more  than  the  transformation  of 
complex  expressions  to  recognizable  form. 
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A l qebr as 


The  aggregate  made  up  of  specific  sets  of  values* 
operators*  and  expressions  form  what  is  called  an  'algebra'. 
Basically  an  algebra  is  a  composite  structure  consisting  of 
operations  and  sets.  The  sets  describe  the  types  of 
operands  and  results.  The  operations  define  all  the  ways 
that  results  are  determined  from  operands.  In  the  general 
case*  the  ooerations  can  have  multiple  operands  of  mixed 
type.  The  tVDes  of  the  operands  are  called  'sorts'. 
Boolean  is  a  sort  of  the  boolean  data  tyoe.  Ooerators  may 
have  multiole  operands  of  mixed  sort  and  give  a  result  of  a 
fixed  sort.  An  operator  is  simply  an  n-ary  function  of  the 
form! 


oo:  A  1  * A2 *  A3* . . . *  An  ->  A 

where  Al*,,.*An*A  are  carrier  sets  of  sort  Sl*...*Sn*S 
respectively.  The  distinction  between  the  'tyoe'  of  a  set 
and  its  name  is  intentional. 


In  our  description  of  an  algebra*  the  operations  are 
assumed  to  be  exolicitly  defined  functions  on  explicitly 
defined  sets.  .  If*  however*  we  intend  to  use  these  concepts 
for  the  soec i f i c at i on  of  real  oojects,  we  must  be  careful  to 
avoid  the  soecifi cation  of  ooerations  or  sets  that  are  not 
construct ible  bv  finitary  methods.  For  example*  the  set  of 
real  numbers  is  not  c on s t r uc t i b 1 e  by  finitary  methods.  Also 
many  of  the  ooerations  used  in  mathematics  assume 
non-finitary  orincioles  in  their  construction.  Thus  it  is 
important  to  use  care  in  the  choice  of  which  principles  we 
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assume  to  construct  the  objects  we  use  to  reoresent  the  real 
oojects  we  are  attemoting  to  specify. 

Ne  must  also  be  sure  that  the  method  of  soecification 
itself  has  no  representational  bias.  In  the  example  above* 
we  do  not  want  to  say  that  the  ooolean  data  type  consists  of 
the  operators  above  on  the  sets  above*  since  there  are  other 
operations  and  sets  that  reoresent  this  type  equally  well. 

Similarly*  we  do  not  wish  to  specify  a  resource  in  a 
computinq  system  as  consisting  of  a  specific  Processor* 
memory*  disk*  etc.  but  by  the  abstract  functional 
properties  these  objects  provide.  However*  we  also  have  to 
account  for  the  situation  in  which  two  systems  which  appear 
functionally  different*  are  in  fact  functionally  equivalent. 


1.3 


Algebraic  Specifications 


The  manner  in  which  alqebraic  specifications  solve 
these  problems  is  by  first  s oec i f y i nq  '  t emp 1  at es '  for  the 
sets  and  operations  that  are  beinq  specified*  and  •axioms* 
for  the  properties  that  any  actual  sets  and  operations  must 
satisfy  to  meet  the  specification.  The  templates  do  not 
make  any  assumptions  about  the  elements  of  the  sets  or  the 
way  that  the  operations  act  on  elements.  All  such 
properties  are  specified  in  the  axioms.  Then  rules  are 
given  to  determine  when  two  'template*  specifications 
specify  the  same  thing.  The  ideas  can  oe  illustrated  with 
the  boolean  data  type. 


First  we  require  that  there  be  exactly  one  set  whose 
'type'  will  oe  described  by  the  name  'Bool'.  There  must  be 
two  'constants'  (0-ary  operations)  of  tyoe  Bool*  named 
'True'  and  'False'.  Then  there  must  be  exactly  two 
ooerations*  one  unary  and  onebinary*  with  names*  'Not'  and 
'And'*  with  aopropriate  functional  type.  Summarizing* 

True:  •>  Bool 
False:  * >  Bool 
Not :  Boo  1  *>  Boo  1 
Bnd:  Boo1*Bool  ->  Bool 

Next*  the  followinq  'axioms'  must  hold: 

Not  C  T  rue )  =  False 
Not ( Not ( x ) )  =  x 
And(True*x)  =  x 
And(False*x)  =  False 
And(x*y)  =  And(y*x) 

And ( A nd C x * y ) * z )  =  And C x *  And ( y * z ) ) 
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The  axioms  above  were  chosen  to  comoactly  describe  what  are 
claimed  to  be  all  the  essential  Drooerties  of  the  operators. 
Note  that  nowhere  is  there  a  soec i f i cat i on  of  the  number  of 
elements  in  any  set  that  olays  the  role  of  '3ool'.  There 
are  constant  ooerations  'True*  and  'False'  whose  values  must 
be  in  the  set  playing  the  role  of  Bool*  but  there  is  no 
guarantee  that  these  values  are  distinct*  or  that  they  are 
the  only  va  1  ues . 

The  above  soec i f i c a t i on  can  be  codified  into  a  compact 
synt  ax  : 

SPECIFICATION  Boolean 
SORTS 

Boo  1 

OPS 

True:  -  >  Bool 
False:  •>  Bool 
Not :  Boo  1  ”>  Bool 
And:  Bool*Bool  ”>  Bool 

AXIOMS 

Not ( T  rue )  =  False 
Not (Not ( x  )  =  x 
And ( T  rue  *  x  )  =  x 

And(False*x)  -  False 
And(x*y)  =  And(y*x) 

A nd ( A nd C x * y ) *  Z  )  “  A nd ( x *  A nd ( y , z  )  ) 


Algeoraic  specifications  always  occur  in  two  parts. 
The  first  Part  includes  the  sorts  and  the  ops  and  is  called 
the  signature.  The  second  part  consists  of  the  axioms.  The 
axioms  above  are  described  as  equations  between  terms  with 
free  variables.  Axioms  may  also  be  'conditional  equations'. 
A  equation  is  conditional  if  it  has  the  form: 

El*E2*...*En  =>  E 

where  E l * E2 * . . . * En *  and  E  are  equations  between  terms. 

rte  say  that  an  algebra  has  the  same  signature  as  a 
soec i f i cat i on  if  there  is  a  one  to  one  correspondence 
between  the  sorts  and  operations  of  the  specification  and 
the  carrier  sets  and  the  operations  of  the  algebra  that  is 
consistent  with  the  type  properties  of  the  ooerations  in  the 
soec i f i cat i on. 

If  'Bool'  is  associated  to  the  set  { T * F } * ' T r ue ' i s 
associated  to  the  constant  function  whose  value  is  T* 
'False'  is  associated  to  the  constant  function  whose  value 
is  F*  'Not'  is  associated  to  the  unary  operator  ■» *  and  'And' 
is  associated  to  &*  then  it  follows  that  the  algebra  we  have 
discussed  previously  satisfies  the  above  soec i f i c a t i on . 
Also  this  algebra  clearly  satisfies  the  axioms.  Note 
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however  there  are  many  other  alqebras  that  also  satisfy  the 
aoove  s oe c i f i c a t i on  .  For  example*  associate  to  the  sort 
'Bool*  the  set  ia).  Associate  to  the  0-ary  operators  'True' 
and  'False'/  the  constant  function  on  {a>  whose  value  is 
'a'.  Associate  to  'Not'  the  trivial  unary  function  on  {a> 
that  is  the  identity.  Associate  to  'And'  the  trivial  binary 
function  on  (a).  This  algeDra  has  the  correct  signature  and 
it  is  not  difficult  to  show  that  it  satisfies  the  axioms. 
Vet  we  would  not  say  this  second  algeora  is  representative 
of  the  'Boolean'  tyoe.  Thus  there  is  a  clear  distinction 
between  an  algebraic  specification  and  an  algebra. 

In  the  approach  of  'algeoraic  semantics'/  the  meaning 
of  a  specification  is  given  by  a  class  of  algebras  that  is 
uniquely  associated  to  the  specification.  In  the  current 
work  on  aostract  data  types  there  are  two  complementary 
semantics  associated  to  algeoraic  specifications.  To 
describe  these  we  first  need  some  additional  concepts. 


1.4  The  Herbrand  Construction 

Recall  that  a  specification  consists  of  a  pair  (S/E) 
where  S  is  a  signature  and  E  is  a  set  of  axioms.  Let  ALG(S) 
denote  the  set  of  all  S-alqebras/  algebras  whose  signature 
is  S.  Given  S,  how  do  we  know  that  there  exists  any 
algebras  in  Ala(S)  ?  And  given  that  such  S-algebras  exist/ 
how  do  we  know  that  there  exist  S-alqebras  that  satisfy  the 
axioms  E  ? 

Given  a  specification  (S/E)/  define  the  set  of  all 

formal  free  terms/  T  e  r  m  (  X  ,  S  )  /  according  to  the  following 
rules: 

1.  If  t  is  a  0-ary  operator  or  free  variable  of  sort  S/ 

then  t  is  a  term  of  sort  s. 

2.  If  t 1 /  t2/  ...  /tn  are-terms  of  sorts  si/  s2/  .../sn/ 

and  t  is  an  operator  of  characteristic 

t:sl/s2/....sn  ->  s 


then 


t  (t 1 / 12, . . . , tn) 
is  a  term  of  sort  s. 

Let  Term ( S )  denote  the  set  of  all  terms  that  do  not 
contain  any  free  variables.  Note  that  both  Term(X,S)  and 
Term(S)  consist  of  terms  of  different  sorts.  Denote  the 
terms  in  Term(S)  of  sort  s  by  Term(SHs).  The  sets 
Term(SMs)  can  now  be  viewed  as  carriers  in  a  S-algebra 
Term(S).  The  operations  on  this  algebra  are  associated  to 
the  operator  templates  of  S.  If  op  is  an  operator  template 
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of  characteristic  sl*s2*...*sn  ->  s  define  the  ooeration 

f-oo  from  Ter  m  (S )(  s  1)  *...*  Term  (  S )(  sn)  to  Term(SMs)  by: 


f-oo( t 1 *  . . • * tn)  =  oo ( t 1 *  . . . * t n ) 


where 

tl*««.*tn  are  terms  of  sort  sl»...rsn 

The  formal  construction  used  to  create  Term(S)  is  called  the 
Herbrand  construction  in  the  mathematical  literature. 

In  the  case  of  the  Bool  earn  soec i f i cat i on  above»  the 
term  algebra  consists  of  all  the  term  exoressions  we  can 
form  abiding  oy  the  type  characteristics  of  each  operator 
temol ate. 

There  is  another  equivalent  description  of  the  sets  of 
terms  determined  by  a  signature.  rte  can  view  the  terms  as 
strings  on  the  alphabet  consisting  of  the  operator  names* 
the  comma*  left  and  right  parentheses*  and  some  finite 
alphabet  of  symbols  for  free  variables  of  different  sorts. 

Then  the  set  of  terms  forms  a  language  on  this  alphabet  with 
the  following  grammar: 

For  each  sort  s  in  S  add  the  production  rule: 

<Term(S)>  ->  <Term(S)(s)> 

For  each  operator  of  ch arac t er i st i c : 

op:  sl*s2*...*sn  ->  s 
add  the  rule: 

<Term(S)(s)>  ->  ' op ('< Te rm C S )( s 1 )>'* 1 ...'*'< Te rm ( S )( sn )>') ' 


For  each  free  varia-ble  X  of  sort  s*  add  the  rule: 
<Term(S) (s)>  ->  ' X ' 


It  is  not  difficult  to  see  that  the  resulting  grammar  is 
LL(1),  and  therefore  parsaole  by  simple  and  efficient 
methods.  In  particular  there  are  automatic  parser 
generators  that  will  take  the  sianature  of  a  specification 
as  input  and  generate  a  table  driven  parser  for  terms 
defined  for  the  given  signature.  The  resulting  parse  tree 
can  in  fact  be  used  as  a  reor es en t a t i on  of  the  term  for  use 
in  raoid  prototyping.  Essentially  this  is  the  theoretical 
justification  for  the  methods  implemented  in  Guttag* 
Horowitz*  and  Musser  [19781. 
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1  .5 


Congruences 


An  equivalence  relation  R  on  a  S-algebra  A  is  called  a 
congruence  if: 

1.  R-equi va 1 ent  elements  have  the  same  sort 


2.  If  (tl#tl ')# (t2#t2' )#...# <tn#tn' )  are 
elements  of  sorts  s . . . »sn  and  oo  is 
sl*s2*...*sn  ->  s*  then  od ( t 1 * . . . *  t n )  is 
oo(tl'*.««*tn'). 


oairs  of  R-equivalent 
an  operation  of  tyoe 
R-equi valent  to 


If  R  is  a  congruence  on  a  S-algebra  A *  then  there  is 
induced  on  the  equivalence  classes  A/R  a  natural  S-alqebra, 
called  the  quotient  algebra  (Gratzer  11968]). 


1.6  Initial  Algebras 

If  (S,E)  is  a  soec  i  f  i  cat  i  on»  there  are  two  canonical 
congruences  induced  on  the  term  alqebra  Term(S)  by  the 
axioms  E.  These  two  congruences  then  induce  two  quotient 
algebras  on  Term(S),  called  the  'initial  quotient  algebra’ 
and  'final  quotient  algebra'. 

The  first  congruence  will  oe  denoted  Ini t i a  1  (S*E) *  and 
the  second  will  be  denoted  Fina1(S*E).  Initial (S»E)  is 
defined  by  the  following  rule: 

(t*t')  are  Initial (S*E)-equivalent 
i f  and  only  if 

t  =  t*  can  be  proved  from  the  axioms  of  E 

The  axioms  as  expressed  are  equations  between  terms  of  the 
'free  term  algebra'  associated  to  the  algebra.  This  free 
algebra  includes  terms  with  free  variables  of  the 
appropriate  sort.  For  example*  in  the  axioms  for  the 
Boolean  type  there  occur  axioms  such  as: 


And ( T  rue ( ) *  x )  =  * 

The  variable  x  is  a  free  variable  of  sort  Bool.  The  rules 
for  Proving  equations  from  axioms  and  other  oroven  equations 
are  given  by : 

1.  Any  axiom  is  a  oroven  equation.  Any  conditional  axiom  is  a 
valid  rule  of  inference  for  oroving  equations  from  proven 
equa  t i on  s . 

2.  If  in  a  Proven  equation*  every  occurrence  of  a  free  variable 
is  replaced  by  a  single  term  of  the  same  sort  as  the  variable* 
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the  resulting  eauat i on  is  oroven. 

3.  If  in  an  equation,  some  term  is  reolaced  bv  a  term  Drovably 
equal  to  it,  the  resulting  equation  is  Droven. 

4.  Any  equation  derived  from  oroven  equations  by  the  use  of 
the  reflexive  law,  symmetric  law,  or  transitive  law  for 
equality,  is  also  Droven. 

With  the  above  rules,  it  is  not  difficult  to  Drove  that  the 
relation  defined  by  all  Dairs  of  orovaoly  equal  terms  (with 
or  without  free  variables)  is  a  congruence. 


1.7 

Final  Algebras 

The  set  of  terms  of  a  soecific  sort  s  in  the  initial 
quotient  algeora  defined  by  a  s oec i f i c a t i on  (S,E)  is  said  to 
be  'trivial1  if  using  the  axioms  E,  any  two  terms  t,  t'  of 
sort  s  are  orovably  equal. 

Given  a  soec i f i c at i on  (S,E),  we  say  that  an  equation 
between  two  terms  t  =  t '  of  a  non-trivia!  sort  s  in  the  free 
term  algebra  is  'consistent'  with  the  axioms  E,  if  in  the 
soecification  defined  by  the  axioms  E  with  the  additional 
axiom  t  =  t',  the  set  of  terms  of  sort  s  is  not  trivial.  It 
follows,  for  examDle,  that  any  provable  equation  is 
consistent.  However,  there  may  be  consistent  equations  that 
are  not  provable.  Define  the  relation  Final(S,E)  on  terms 
of  the  free  term  algebra  Term(S)  by: 

t,  t'  are  Final(S,E)  -  equivalent 

iff 

t  =  t'  is  consistent  with  the  axioms  E 

It  can  be  Droved  that  the  relation  Final(S,E)  is  a 
congruence.  The  cor resbondi ng  quotient  alqebra  is  called 
the  'final  algebra'  defined  by  the  soec i f i c at i on  (S,E). 


1  .8 

Algebra  Morohisms 

So  far,  we  have  shown  that  a  soecification  (S,E) 
determines  two  SDecific  S-algebras,  the  initial  S-algebra 
and  final  S-algebra.  How  are  specifications  related  to 
other  alqebras  ?  For  example,  we  have  given  a  soecification 
for  the  Boolean  type.  How  is  this  specification  related  to 
an  algebra  that  seems  to  realize  the  specification  ? 
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Given  two  S-alqebras  A  and  8,  a  corresDondence  H 
associating  each  carrier  set  of  A  to  a  carrier  set  of  8,  and 
each  operation  of  A  to  an  ooerat i on  of  3  is  said  to  be  an 
S-homomorph ism  if: 

1.  the  co r r esoondence  between  carrier  sets  preserves  the 
sort  t  yoe . 

2.  the  correspondence  between  ooerators  preserves  the 
ooerator  characteristics. 

3.  if  tl*..«*tn  are  elements  of  sorts  si sn  in  A 
and  oo  is  an  ooerator  in  A,  then 

H(oo(tl»...»tn))  •  H(op)(d(tl)*...»H(tn)). 

An  S-homomorph i sm  is  called  an  S-monomo r oh i sm  if  each 
correspondence  between  carrier  sets  is  injective.  An 
S-homomorph ism  is  called  an  S-eoimorphism  if  each 
correspondence  between  carrier  sets  is  a  surjection.  And  an 
S-homomorph i sm  is  called  an  S- i s omorph i s m  if  each 
correspondence  between  carrier  sets  is  a  bijection. 

S-homomo rph i sms  are  intimately  associated  to 
S-congruences.  If  H  is  an  S-homomorph ism  between  S-algebras 
A  and  B*  define  the  relation  R(rl)  on  the  S-alqeora  A  by: 

For  any  sort  s  in  the  signature  S  *  let  A  ( s )  be  the  carrier 
of  sort  s  in  the  alqebra  A,  and  let  H(s)  be  the 
correspondence  determined  by  H  oetween  the  carriers  of  A  and 
B  of  sort  s. 

a*  a'  in  A(s)  are  R(H)  -  equivalent 
i  f  f 

H(s)  (a)  =  H ( s ) ( a ' ) 

It  is  not  difficult  to  show  that  R ( H )  is  an  S-conqruence. 
It  is  the  S-congruence  canonically  associated  to  the 
S -h o momo r oh i s m  H. 

Given  any  S-alqebra  A,  there  is  a  canonical 
S-homomoroh i sm  Val(A)  from  the  term  alqebra  Term(S)  to  A, 
determined  dv  evaluating  each  formal  term  of  Term(S)  through 
its  corresponding  terms  in  A.  There  is  then  an  S-congruence 
R(Val(A))  on  Term(S)  induced  by  Val(A).  For  convenience* 
this  congruence  will  be  denoted  R(A). 


1.9 


Algebraic  Semantics 
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At  this  ooint  we  have  all  the  conceotual  tools  we  need 
to  precisely  describe  the  two  classes  of  algebras  that  will 


class 

that 


(S,E) 


Each 


normally  be  used  to  interoret  a  specification 

of  algebras  will  determine  one  of  the  two  meanings 
a  specification  determines,  hence  the  terminology 


'algebraic  semen t i cs 


,e  c/he  'ir,it’al  algebra'  semantics  of  a  soec  i  f  i  cat  i  on 
(5,c)  is  the  class  of  all  S-alqebras  A  such  that: 

1  •  S-homomorphi sm  Val(A)  from  Term(S)  to  A  is  an 

S  -  e  p  i  m  o  r  p  h  i  s  m , 

2.  the  S-congruence  RCA)  on  Term(S)  is  identical  with 
Initial  (SrE). 


The  'final  algebra'  semantics  of  a  specification  (S,E) 
is  the  class  of  all  S-alqebras  A  such  that: 

1,  the  S-homomorphi sm  Val(A)  fr0m  Term(S)  to  A  is  an 
S-eoi morphism, 

2.  the  S-congruence  RCA)  on  Term(S)  is  identical  with 
F  i  n  a  1  (  S  ,  E  )  . 

It  follows  that  the  initial  quotient  algebra  is  an  element 
of  the  class  of  initial  algebras,  and  similarly,  the  final 
quotient  algeora  is  in  the  class  of  final  algebras.  It  is 
not  difficult  to  orove  that  any  two  S-algebras  in  the  class 
of  'initial  algebras'  are  S- isomorphic.  Similarly  all  the 
S-algebras  in  the  class  of  'final  algebras'  are 
S-i somorphi c.  Thus,  in  effect,  anv  alqebra  in  the  class  of 
initial  algebras  is  isomorohic  to  the  quotient  initial 
algebra  constructed  from  the  term  algebra  and  the 
Initial CS,E)  congruence.  Similarly  for  final  algebras. 

The  aoove  characterizations  of  the  meaning  of  a 
soeci f icati on  can  be  used  to  effectively  determine  if  a 
specification  'means'  what  we  want  it  to  mean.  For  example, 
in  the  examole  for  Boolean,  we  started  with  an  algebra 
consisting  of  a  set  C  T ,  F  >  and  o  aerations  '&'  and  The 
operations  were  defined  explicitly  with  a  truth  table.  rie 
then  created  a  formal  specification  Boolean  that  we  claimed 
caotured  the  'essence'  of  the  boolean  data  type. 
Soeci fically  we  should  be  able  to  orove  that  the  explicit 
algebra  is  a  member  of  the  class  of  initial  or  final 
alqebras  defined  by  the  specification.  Define  a 
S-homomoroh i sm  H  from  Te r m C Bo o 1 ean )  to  alqebra  A  by: 

TrueO  ->  T 
Fal seC)  ->  F 
Mot  - >  i 
And  ->  & 
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H  is  clearly  a  surjection  from  Te rm ( 800 1 ean )  to  {T,F}. 
Consider  the  relation  RCA)  induced  on  Term(Boolean)  by  A. 
We  will  show  that  it  equals  the  relation  I n i t i a  1  ( S * E ) *  where 
E  is  the  set  of  axioms.  We  have  to  show  that  two  terms 
evaluate  in  A  to  the  same  value  if  and  only  if  the  terms  are 
orovably  equal  using  the  axioms  in  E.  Let  the  size  of  a 
term  oe  the  number  of  operators  in  the  term.  We  will  first 
Drove  by  induction  on  the  size  n  of  the  largest  of  the  two 
terms  that  if  two  terms  evaluate  in  A  to  the  same  result* 
then  they  are  provably  equal  from  E. 

First  we  prove  the  following: 

Lemma:  if  t  evaluates  to  T*  then  t  is  orovably  equal  to 
True*  and  if  t  evaluates  to  F,  then  t  is  orovably  equal  to 
False. 

Proof:  Induct  on  the  size  n  of  t .  If  n  =  1*  the  result  is 
oovious.  Assume  true  for  n  <=  N  and  assume  n  s  N  ♦  1.  The 
term  t  has  the  form  t  =  Not(x)  or  And(x,y)  for  some  terms  x 
and  y  of  size  <-  N.  If  t  =  Not(x),  and  t  evaluates  to  T, 
then  Not(MotCx))  =  x  evaluates  to  "'T  =  F,  and  x  has  size  <  = 
N  *  therefore  x  is  orovably  equal  to  False.  But  then  t  s 
Not(x)  is  provably  equal  to  Not(False)*  hence  orovably  equal 
to  Not ( Not ( T rue ) )  =  True.  Similarly  if  t  evaluates  to  F. 
If  t  =  And(x,y)*  and  t  evaluates  to  T*  then  x  and  y  must 
evaluate  to  T  also.  Since  the  size  of  x  and  y  <=  N*  x  and  y 
are  provably  equal  to  True.  But  then  from  the  axiom 
And(True*x)  =  x*  it  follows  that  t  =  And(x*y)  is  orovably 
equal  to  True.  Similarly  if  t  evaluates  to  F. 

Clearly  every  expression  evaluates  to  T  or  F. 
Therefore  if  two  expressions  evaluate  to  the  same  value  by 
the  above  they  are  Drovably  equal  to  each  other. 
Conversely*  if  two  exoressions  are  provably  equal  to  each 
other*  then  they  must  evaluate  to  the  same  value*  since  the 
operators  corresponding  to  each  operator  temolate  satisfies 
the  corresponding  axioms. 

Thus  the  quotient  aloebra  defined  by 
T e r m ( Boo  1 ean ) / 1 n i t i a  1 ( S * E )  is  isomorphic  to  the  algebra  A* 
and  A  is  an  'initial  alqeora'  for  the  specification. 

Moreover*  note  that  the  'trivial'  alqebra  consisting  of 
the  (a)  and  the  operations: 

T  =  F  =  a*  "’(a)  -  a*  £(a*a)  -  a 

has  the  correct  signature  but  is  not  in  the  class  of 
'initial  algebras'  defined  by  the  specification*  since  in 
this  algebra  True  and  False  evaluate  to  the  same  value*  but 
are  not  provaply  equal. 
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Is  the  algebra  A  in  the  class  of  'final  algebras' 
defined  by  the  sane  soec  i  f  i  c a t  i  on  ?  Equ i v a  1 e nt 1 y #  are  the 
relations  R ( A )  and  Final(S#E)  the  same  ?  By  what  we  have 
already  oroved  it  is  sufficient  to  ask  whether  there  are 
terms  t #  t'  that  are  consistent#  but  not  orovably  equal.  If 
t  and  t'  are  consistent#  then  from  E  and  the  equation  t  = 
t'»  it  does  not  follow  that  True  and  False  are  Drovably 
equal.  But  if  t  and  t'  are  not  orovably  equal#  then  they 
evaluate  to  different  values  T  and  F»  say.  But  then  by  the 
lemma  t  is  orovably  equal  to  True  and  t'  is  orovably  equal 
to  False#  and  hence  from  the  equation  t  =  t ' #  True  is 
Drovably  equal  to  False.  Therefore  if  t  and  t'  are 
consistent#  they  are  orovably  equal.  Clearly  if  t  and  t' 
are  Drovably  equal#  then  they  are  consistent. 

The  above  arguments  show  that  for  the  soecifi cation 
Boolean#  the  initial  algebra  and  final  alqebra  semantics  are 
the  same.  It  is  a  theoretical  fact  that  there  exist 
soecifi cat  ions  for  which  this  is  not  the  case.  This  will 
become  fairly  evident  when  the  comoutability  of  a 
s oec i f i c a t i on  is  discussed  in  a  later  section. 

In  the  case  of  Boolean#  the  axioms  enable  us  to 
formally  evaluate  each  term  in  terms  of  constant  terms.  For 
example,  to  evaluate  And ( No t ( Fa  1 se ) # T r ue ) : 

And ( Not ( Fa  1 se ) » T r ue )  =  And ( T r ue # Not ( Fa  1 s e ) ) 

And ( T rue # Not ( Fa  1 se  )  )  =  Not(False) 

Not(False)  =  NotfNot(True)) 

Not ( Not ( T rue )  )  =  True 

In  fact#  the  tables  describing  the  operations  exolicitly 
(which  also  determine  an  equational  soecifi cation#  without 
free  variables)  is  derivable  from  the  above  equations.  The 
advantage  of  the  equational  soec i f i c at i on  with  free 
variables  is  its  comoactness. 

Ordinarily#  it  cannot  be  assumed  that  every  term  is 
Drovably  equal  to  a  constant  term.  It  is  often  the  case  in 
the  theory  of  abstract  data  tyoes  for  examole#  that  the 
number  of  distinct  classes  of  unequal  terms  is  infinite. 


2.0 

Prooerties  of  Specifications 

Now  that  the  basic  conceots  of  our  methodology  have 
been  described#  we  want  to  determine  if  it  can  be  used  to 
fulfill  the  requirements  of  a  methodology  for 
soec i f i c  a  t i ons . 
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2.1 

Equivalence  of  Soec i f i c at i ons 

First  It  Is  possible  to  define  when  two  soec i f 1  cat  1 ons 
with  the  sane  signature  have  the  same  meaning#  in  the  two 
i nt eroret at i ons  of  meaning  discussed  aoove.  Two 

soecifi cations  (S#E)  and  (  S  #  E  '  )  with  the  same  signature  have 
the  same  initial  algebra  semantics  when  they  determine  the 
same  class  of  initial  algeoras.  Similarly#  they  have  the 
same  final  algebra  semantics  when  they  determine  the  same 
class  of  final  algebras.  It  follows  from  the  above  that  two 
specifications  (S#E)  and  ( S  #  E  * )  have  the  same  meaning  in 
initial  algebra  semantics  if  and  only  if  the  axioms  E  are 
Drovably  equal  from  the  axioms  E'  and  conversely.  Similarly 
two  specifications  (S#E)  and  (  S  #  E  '  )  have  the  same  final 
algebra  semantics  if  and  only  if  any  equation  of  formal 
terms  t  =  t'  is  consistent  with  E  if  and  only  if  it  is 
consistent  with  E  '  . 

The  above  definitions  allow  us  to  determine  when  two 
soec i f i cat i ons  with  the  same  siqnature  but  different  axioms 
have  the  same  meaninq.  rthat  about  specifications  that  have 
different  signatures  ? 

Assume  that  (S#E)  and  ( S • #  E  * )  are  two  soec i f i c at i ons  . 
A  c o r r esoondenc e  H  between  S  and  S'  is  called  a  Poincare 
transformation  if: 

1.  for  every  sort  s  in  S#  H(s)  is  a  sort  in  S' 

2.  for  every  operator  op  in  S  of  characteristic 

sl#s2#...#sn  ->  s# 

H(op)  is  an  operator  in  S'  of  characteristic 
rl(sl)#H(s2),...#H(sn)  ->  H(S) 

Clearly#  H  induces  a  correspondence  between  Term(S)  and 
Term(S').  If  H  is  bijective  between  S  and  S'#  then  H 
induces  a  bijection  between  Term(S)  and  Term(S').  Thus  each 
equation  t  =  t  1  in  Term(S)is  maDoed  to  an  equation  H(t)  = 
H(t')  in  Term(S').  In  this  case  the  spec i f i c at i ons  (S#E) 
and  (S'#E')  are  semantically  equivalent  in  the  sense  of 
initial  algebras#  or  final  algeoras#  when  the  specifications 
(  S  '  #  E  '  )  and  (S'#H(E))  are#  and  the  question  of  equivalence 
reduces  to  the  previous  case.  These  cases  cover  the  cases 
that  correspond  to  a  renaminq  of  sorts  or  ooerators#  in 
addition  to  a  change  in  the  axioms. 

In  qeneral#  two  specifications  have  the  same  semantics 
when  they  determine  the  same  class  of  aloebras. 
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2.2 

The  Adequacy  and  Computability  of  Alqebraic  Specifications 

In  this  section  we  examine  the  ability  of  this 
specification  methodology  to  define  all  the  types  of  objects 
that  we  miaht  want  to  define.  This  is  the  'adequacy' 
problem.  Bergstra  and  Tucker  (19831  have  written  a  series 
of  papers  dealing  with  this  question  and  we  will  summarize 
their  i deas  here. 

Given  a  specification  (  S  ,  E  )  and  an  S-algebra  A,  we  say 
that  A  is  'effectively  presented'  whenever  we  possess  an 
effective  enumeration  of  its  elements  and  we  can  effectively 
calculate  its  operations.  The  algebra  A  is  said  to  be  a 
' semi comput abl e  algebra',  or  a  ' cosemi comout abl e  algebra'  if 
in  addition  the  equality  relation  of  A  is  recursively 
enumerable,  or  co’recursi ve 1 y  enumerable,  respectively. 
(Recall  that  a  set  is  co-recurs i vel y  enumerable  if  its 
complement  is  recursively  enumerable).  A  is  a  'computable 
algebra'  when  equality  is  decidable. 

Since  for  initial  semantics  two  terms  are  equal  if  and 
only  if  they  are  orovably  equal  from  the  axioms,  and  since 
all  such  proofs  can  be  enumerated,  the  initial  algebra  of  a 
specification  is  semi  computable.  It  is  less  obvious,  but 
also  true,  that  the  final  algeora  of  a  soec i f i cat i on  is 
co-semi  computable.  Mote  that  if  an  alaebra  is  both 
semi comout aol e  and  co-sem i c omout ab 1 e ,  then  the  equality 
relation  between  terms  is  decidable. 

Of  more  interest  to  the  question  of  adequacy  ,is  the 
converse  of  these  facts.  Is  every  s em i c omou t ab 1 e  algebra 
the  initial  algebra  of  some  specification  ?  Is  every 
co-semi comout abl e  algebra  the  final  algebra  of  some 
specification  ?  Is  every  computable  algebra  both  the  final 
algebra  of  some  specification  and  the  initial  algebra  of 
some  specification  ?  Bergstra  and  Tucker  (19831  have  been 
aDle  to  prove  the  second  and  last  of  these  assertions,  given 
that  the  specifications  may  include  conditional  equations. 

Theorem  (Berqstra  and  Tucker).  An  algebra  is  s em i c omput ab  1  e 
if  and  only  if  it  is  the  final  alqebra  of  a  finite 
conditional  specification. 

Theorem  (Bergstra  and  Tucker).  An  algebra  is  computable  if 
and  only  if  it  is  both  the  initial  algebra  of  a  finite 
conditional  specification  and  the  final  algebra  of  a  finite 
conditional  specification. 

Bergstra  and  Tucker  also  show  that  the  set  of  functions 
computed  by  LOOP  programs  on  the  natural  numbers  compose  a 
data  type  which  has  a  finite  conditional  soec i f i c at i on  using 
final  algeora  semantics,  out  does  not  possess  an  effective 
specification  of  any  kind  using  initial  algebra  semantics. 
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The  fact  that  individually,  initial  and  final  semantics  do 
not  attach  the  same  semantics  to  alqebraic  secifications  is 
one  reason  why  both  conceots  need  to  oe  introduced.  There 
is  another  more  oractical  reason  however.  It  is  reasonable 
to  require  that  the  soec i f i cat i ons  of  some  resources  be 
computable.  Presumably  the  functional  behavior  of  most 
physical  devices  is  decidable. 

Unfortunately,  the  characterization  of  the 
computability  of  a  specification  given  by  Bergstra  and 
Tucker  is  not  generally  oractical.  In  order  to  make  the 
methodology  oractical  we  need  simple  but  broad  criteria  for 
insuring  the  computability  of  a  specification. 

One  aooroach  to  this  Drool em  is  to  determine  if  the 
axioms  define  rewrite  rules  that  allow  one  to  prove  that 
each  term  without  free  variables  can  be  reduced  to  a  normal 
form.  To  do  this  it  is  necessary  to  prove  some  kind  of 
Church  Rosser  property  for  normal  forms,  to  guarantee  their 
uniqueness. 


2.3  Specification  Syntax 

Now  that  the  basic  conceots  underlying  the  methodology 
of  algebraic  specifications  have  been  introduced  we  can 
illustrate  how  these  concepts  are  used  in  practice.  First 
we  need  to  establish  a  syntax  for  describing  a 
specification.  Rather  than  give  a  grammar,  we  will  describe 
the  templates  used  for  specifications.  An  example  of  the 
form  of  a  soec i f i cat i ons  was  given  above  for  the  boolean 
data  tyoe.  A  template  for  this  form  is: 

SPECIFICATION  <Soeci  fication*-identi  fier> 

OPERANDS 

<0oerand«*1  i  st  > 

OPERATORS 

<0dc  r a  t  o  r«*  1  ist> 

AXIOMS 

<  A  x  i  o  m  ♦*  1  ist> 


If  is  convenient  to  have  a  specification  syntax  that 
facilitates  the  Combination  and  extension  of  specifications 
to  provide  a  modular  approach  to  complex  specifications. 
Although  ultimately,  a  specification  should  always  be 
expressible  in  the  above  form,  it  is  convenient  to  eliminate 
expressive  redundancy  through  a  more  compl ex _ synt ax .  For 
example,  we  want  to  provide  a  facility  for  readily 
incorporating  a  commonly  used  specification  into  a  new 
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specification.  The  syntax  used  to  incorporate  a  previously 
defined  soec i f i cat i on  into  a  new  specification  is: 

SPECIFICATION  <New«-speci  ficationHdenti  fier> 

EXTEND 

<01d«-speci  fication«-identifier«-l  ist> 

BY 

OPERANDS 

<0oe  r  and*- 1  ist> 

OPERATORS 

<0pe  r  a  t  o  r  *- 1  ist> 

AXIOMS 

<  A x  i  om*- 1  ist> 

The  semantics  of  such  an  extended  specification  are  the 
semantics  of  the  composite  specification  as  if  it  were 
written  without  extension.  The  properties  of  the  extension 
may  involve  the  operands  and  ooerators  of  both 

specifications.  Thus  in  an  extension  the  semantics  of  a 
previously  defined  specification  could  change  within  the 
context  of  new  operands*  operators*  and  properties.  In  most 
cases  such  semantic  changes  are  undesirable.  Thus*  we  need 
a  criterion  for  when  such  changes  do  not  occur.  In  the 
process  of  determining  such  a  criterion  we  will  also 

illustrate  the  use  of  the  semantic  interpretation  associated 
to  a  specification. 

Assume  ( S , E )  and  ( S  *  *  E  * )  are  two  specifications  for 
which  S  is  a  subset  of  S'  and  E  is  a  subset  of  E'.  First 
let  us  consider  initial  alqebra  semantics.  In  this  case* 
the  relation  Initial (S**E'  )  is  a  subset  of  the  relation 
Ini t i al (S ' , E ' )  since  every  formal  term  in  TermCS)  is  also  a 
term  is  Term(S’),  and  if  t  and  t'  are  orovably  equal  in  E, 
they  are  orovably  equal  inE'  since  E  is  a  subset  of  E'. 
The  terms  in  Term(S)*  viewed  as  terms  in  Term(S')  will  have 
the  same  oroperties  in  ( S  *  *  E  * )  as  the  orooerties  in  (S*E)  if 

and  only  if  any  two  terms  t  and  t'  in  Term(S)  that  are 

Ini t i al CS ' , E ' )  related  are  also  Initial CS,E)  related.  In 
other  words,  if  the  restriction  of  the  relation 
Initial (S' »E')  to  TermCS)  equals  the  relation  Initial (S*E). 

rte  say  that  a  specification  (S,E)  is  persistent  in  an 
extended  specification  CS'E')*  in  the  sense  of  initial 
semantics*  if  the  relation  Initial CS**E*)  restricted  to 
TermCS)  equals  the  relation  I n i t i a  1 ( S * E )  . 

If  S  is  a  'subsignature'  of  S'  and  A  and  A'  are 
S-algebras  and  S'-algebras  respectively*  then  A  is  said  to 
be  a  subalgebra  of  A'  if  there  is  a  S-monomo r oh i s m  from  A  to 
A'.  Similarly*  we  say  that  a  specification  (S,E)  is 
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□  ersi stent  in  an  extended  specification  (  S  '  # E  '  ) #  in  the 
sense  of  final  semantics#  if  the  relation  FinalCS' *  E  * ) 
restricted  to  Term(S)  equals  the  relation  Final(S#E). 

The  following  theorems  can  now  be  Droved. 

Theorem:  (S,E)  is  a  oersi stent  subsoec i f i cat i on  of  (S'»E')» 
in  the  sense  of  initial  semantics#  if  and  only  if  the 
initial  algebra  of  (S#E)  is  a  subalgeora  of  the  initial 
alqebra  of  ( S ' #  E ' ) . 

Theorem:  (S#E)  is  a  oersi stent  subspecification  of  ( S  '  #  E  ' ) # 
in  the  sense  of  final  semantics  if  and  only  if  the  final 
algebra  of  (S,E)  is  a  subalgeora  of  the  final  algebra  of 
(  S  '  #  E  '  )  . 

Although  these  results  are  essentially  theoretical  they 
are  the  basis  for  at  least  one  Dractical  test  for 
persistency*  In  the  examole  given  for  boolean  we  showed  how 
to  verify  the  correctness  of  a  soec i f i c at i on  by  establishing 
a  maooing  between  the  soec i f i cat i on  and  an  algebra  that  is  a 
canonical  represent  at i ve  of  the  data  type.  Soec i f i c a t i ons 
may  often  be  obtained  in  this  way  in  practice.  If  the  data 
type  is  computable#  this  algebra  is  both  a  final  and  initial 
algebra  for  the  specification.  If  the  specification  is 
extended#  then  it  will  be  persistent  in  the  extended 
specification  if  and  only  if  its  canonical  algebra  is  a 
subalgeora  of  a  canonical  algebra  for  the  extension. 


2. a 

Derived  Algebras  and  Specifications 

Given  an  algebra  of  signature  S  and  a  term 
t ( x 1 # x 2 # . . . # x n )  with  free  variables  of  sorts  sl#s2#...#sn 
and  return  sort  s#  we  can  view  t  as  defininq  an  operator  of 
charact er i st i c  sl#...#sn  ->s.  Such  an  ooerator  is  called  a 
derived  operator  of  A.  More  generally#  an  algebra  B#  whose 
sorts  are  a  subset  of  the  sorts  of  A#  and  whose  operators 
are  derived  ooerators  of  A#  is  called  an  alqebra  derived 
from  A.  The  signature  of  B  is  also  said  to  be  derived  from 
the  signature  of  A.  For  examole# 

Imp(xl#x2)  =  No t ( And C x 1 » No t ( x 2 )  ) 

is  a  derived  operator  in  Boolean.  This  is  the  well  known 
'implies'  operator. 

If  (S#E)  and  (S'#E')  are  specifications#  and  S'  is  a 
signature  derived  from  S#  we  say  that  the  initial  semantics 
of  ( S '  #  E '  )  are  consistent  with  the  initial  semantics  of 
(S#E)  if  given  any  terms  t  and  t'  of  Term(S')#  if  (t#t')  is 
in  In i t i a  1 ( S  '  , E  '  )  then  (t»t')  is  in  I  n i t i a  1 ( S # E ) .  rte  say 
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that  the  initial  semantics  of  ( S '  * E ' )  are  faithful  to  the 
initial  semantics  of  (  S  *  E  )  *  if  for  any  t  *  t'  in  T e r m ( S ' ) * 
C  t  * 1  1  )  is  in  Initial  (SrE)  if  and  only  if  ( t  *  t  '  )  is  in 
Initial  (S'  f E'  )  ,  Similarly  for  final  semantics. 


2.5 


I nt er oret at i ons  and  I  mo  1 ement at i ons 

The  oractical  problem  we  are  attemDting  to  solve 
involves  software  portability.  Spec i f i c a  1 1 y *  we  want  to  be 
aDle  to  specify  resource  interfaces  in  an  implementation 
independent  manner  beginninq  with  physical  interfaces  up  to 
problem  solving  interfaces.  In  this  view*  we  want  to 
successively  build  layers  of  resources  implemented  on 
previously  defined  sublayers.  For  this  reason  it  is  natural 
to  expect  that  an  'implementation'  must  be  determined  by 
relating  one  specification  to  another. 

Alternatively*  we  want  to  realize  a  specification  in 
terms  of  resources  for  which  we  do  not  have  specifications. 
Me  call  such  a  realization  an  interpretation.  An 
interpretation  is  specified  oy  associating  to  each  sort  a 
description  of  the  values  that  will  realize  the  sort*  and  to 
each  operator*  a  function  orocedure  operating  on  the 
appropriate  values.  An  interpretation  is  valid  if  it 
defines  an  algebra  in  the  semantic  class  chosen  for  the 
specification.  Thus  an  interpretation  associates  the 
specification  to  a  specific  'algebra'*  that  is  realized  by  a 
set  of  function  procedures  and  data  types  in  a  program. 

To  implement  a  specification  A  in  terms  of  another 
specification  B  ought  to  mean  that  the  sorts*  operators*  and 
properties  of  A  pught  to  be  implementable  from  those  of  B. 
Therefore  we  make  the  following  definition: 

Given  specifications  (S*E)  -and  (  S  '  *  E  '  )  *  an  implementation  of 
(S*E)  on  ( S '  *  E '  )  *  in  the  sense  of  initial  semantics*  is  a 
Poincare  transformation  H  from  the  signature  S  to  a  derived 
signature  S'*  of  S'  with  the  property  that  the  homomorphism 
induced  from  Term(S)  to  T  e  r  m  (  S  '  '  )  is  consistent  with  the 
congruences  Initial (S*E)  on  Term(S)  and  Initial CS'*E' )  on 
TermCS'').  Op  equivalently*  for  t  *  t  *  in  Term(S)* 

if  ( t  *  t  *  )  is  in  Initial (S*E) 
then 

(H(t)*H(t'))  is  in  Initial (S',E') 


An  implementation  H  is  faithful*  in  the  sense  of 
initial  semantics*  if  in  fact  it  satisfies: 


( t  *  t  '  )  is  in  Initial (S*E) 
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if  and  only  if 

(H(t)*H(t ' ))  is  in  Initial (S' *E') 

We  clearly  have  similar  definitions  for  i mo  1 ement at i ons  in 
the  sense  of  final  semantics. 

Theorem:  There  is  an  i mol ement at i on  of  (S*E)  on  (S',E')  in 
the  sense  of  initial  (final)  semantics  if  and  only  if  there 
is  a  homomorphism  from  the  initial  (final)  algebra  of  (  S  *  E  ) 
to  a  derived  algebra  of  the  initial  (final)  algebra  of 
(S '  ,  E • ) . 

A  nd  * 

Theorem:  There  is  a  faithful  implementation  of  (  S  *  E )  on 
(  S  '  *  E  '  )  in  the  sense  of  initial  (final)  semantics  if  and 
only  if  there  is  a  monomorphism  from  the  initial  (final) 
algebra  of  (S,E)  to  a  derived  algebra  of  the  initial  (final) 
algebra  of  (S  * * E ' ) . 

Though  these  theoretical  results  seem  comforting*  are  there 
any  practical  methods  for  determining  if  a  correspondence  is 
an  i mol ement at i on  or  if  such  an  implementation  is  faithful  ? 

If  H  is  a  correspondence  from  (S*E)  to  (S'*E')  that  assigns 
to  each  sort  s  in  S*  a  sort  H(s)  in  S'*  and  to  each  operator 
f  in  S  *  a  derived  operator  H(f)  of  S' *  then  H  is  an 
implementation  in  the  sense  of  initial  semantics  if  and  only 
if  for  every  axiom  t  =  t  *  in  £ *  the  equation  H(t)  =  H(t')  is 
orovably  equal  from  E'. 


2.6 


Parameterized  Specifications 

Certain  kinds  of  resources  are  naturally  parameterized. 
For  example*  in  the  case  of  the  string  data  type*  strings  of 
integers*  or  strings  of  characters*  or  strings  of  bits  all 
require  many  of  the  same  operations  and  share  many  of  the 
same  properties*  yet  in  most  cases  must  be  defined 
separately.  Parameterized  specifications  are  specifications 
used  to  specify  resources  that  may  be  instantiated  for  a 
number  of  different  resource  parameters*  but  are  not 
uniquely  associated  to  any  of  them.  In  this  section*  we 
introduce  the  basic  ideas  with  a  minimum  of  discussion.  For 
details  of  some  of  the  theoretical  work  in  this  area  see 
Ehrich  11982). 
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3.0 

Pa r am e t e r i z ed  Specification  Syntax. 

The  template  for  a  oaramet er i zed  soec i f i c a t i on  has  the 

form: 

SPECIFICATION  <soecification«"identi  f  i  e  r  > 

PARAMETERS 

OPERANDS 

<oarameter«-ooerand«-l  i  st  > 

OPERATORS 

<oarameter«-ooerator«"l  ist> 

AXIOMS 

<parameter*-axiom«"l  i  st> 


OPERANDS 

<ooerand«-l  i  st  > 

OPERATORS 

<ooeratorH  i  s t > 

AXIOMS 

<ax  i  om«-l  i  st  > 

The  axioms  for  the  body  of  the  oarameteri zed  soec i f i c a t i on 
may  include  operand  classes  and  ooerators  of  the  parameter 
part,  in  addition  to  the  other  operand  classes  and 
ooerators.  The  axioms  of  the  parameter  part  may  include 
only  operand  classes  and  operators  of  the  oarameter  part. 
The  Parameter  part  describes  the  ooerand  classes/  operators/ 
and  axioms  that  must  be  specified  in  any  invocation  of  the 
parameterized  soecifi cation.  The  syntax  of  an  invocation 
i  s : 


<oarm«-spec«-i  dent  >  (  <specH  dent  >  ) 

WHERE 

OPERANDS 

< spec  t-ooe rand>  IS  <oa r m«-soec«"OPe rand> 


OPERATORS 

<spec«-operator>  IS  <oa  r  m«"Spec«"Ope  ra  t  o  r> 


Thus  in  an  invocation/  a  correspondence  is  established 
between  operands  and  ooerators  of  one  specification  (actual 
oarameters)  and  the  ooerand  and  operators  of  the  parameter 
oart  of  the  parameterized  soecifi cat  ion.  For  semantics/  the 
soec i f i ca t i on  resulting  from  such  an  invocation  is  viewed  as 
an  extension  of  the  specification  that  suoolies  the  actual 
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oarameters.  To  be  a  valid  invocation*  the  actual  parameters 
must  satisfy  the  parameter  axioms  as  a  consequence  of  the 
axioms  that  they  already  satisfy.  Also*  to  be  a  valid 
invocation*  the  specification  supplying  parameters  must 
be  persistent  in  the  resulting  specification*  In  the 
resultinq  specification,  as  in  an  extension  of  a 
specification*  the  semantics  must  be  the  same  as  in  the 
actual  parameter  suOsnec i f i cat i on  .  The  significant  point 
from  the  practical  viewpoint  is  that  in  this  case*  as  well 
as  in  the  case  of  soei c i f i cat i on  extension*  we  need 
practical  criteria  for  determining  the  persistence  of  a 
subsoec i f i c  at i on . 


4.0 

Conclusions 

Current  practical  approaches  to  functional 
soec i f i cat i on  are  not  based  on  any  rigorous  foundation*  or 
developed  in  the  context  of  any  qeneral  theory.  This  fact 
precludes  the  development  of  portable  loqical  interfaces*  or 
the  sytematic  specification  of  a  hierarchy  of  logical 
interfaces.  The  approach  taken  here  attemots  to  resolve 
some  of  these  problems.  It  beqins  with  a  model  close  to 
practice*  the  idea  of  an  'algebra'*  consisting  of  operators 
and  operands,  and  establishes  a  syntax  and  semantics  for 
specifications.  Transformations  between  specifications  at 
the  syntactical  level  are  described  by  Poincare 
transformations*  a  concept  used  for  a  lonq  time  in  logic  to 
describe  the  same  process  of  establishing  a  correspondence 
between  the  names  of  the  entities  of  one  formal  theory  with 
those  of  another.  The  semantics  are  established  through 
i nt eroret at i ons  of  the  syntactical  elements  as  elements  of 
certain  algeoras*  depending  on  the  semantics  chosen. 
Relations  oetween  the  semantics  of  two  specifications  are 
established  by  homomorph i sms  between  their  respective 
i nt eroret at i ons .  Every  important  concept  associated  to 
soec i f i cat i ons  can  now  be  given  riqorous  definitions. 

At  the  practical  level*  concrete  resources*  either  in 
software  or  hardware*  are  viewed  as  defining  concrete 
algebras  that  may  serve  to  interoret  a  specification 
faithfully.  Whether  this  assumption  is  reasonable  remains 
to  be  seen.  This  is  the  most  obvious  question  open  to 
further  research.  Moreover*  it  seems  apparent  that  much  of 
the  theorem  proving  technology  develooed  in  recent  years  may 
find  an  aoolication  to  the  analysis  of  soecifications.  In 
any  case*  this  aoproach  has  served  to  form  a  riqorous 
foundation  for  a  theory  of  specification,  and  to  expose  some 
of  the  difficult  issues  that  must  be  addressed  by  any 
aopproach . 
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5.0 

A  Sample  Abstract  Machine 

To  illustrate  the  oractical  ootential  of  this 
specification  technique*  a  soec i f i c at i on  of  an  abstract 
processor  is  included  below.  The  first  Dart  defines  the 
data  tyoes  required  to  define  memory*  values*  and  states. 
The  later  part  defines  the  operations  and  instructions  of 
the  processor.  The  basic  idea  for  such  a  machine  can  be 
found  in  Fase1I1980J. 

The  specifications  below  combine  to  specify^  a  sample 
abstract  machine.  Metasymbols  describing  the  form  of  the 
specification  are  capitalized. 

CONVENTION 

A  binary  od  X:  Elem*  Elam  ->  Elem  is 
COMMUTATIVE 

if  X  (  x  *  y  I  =  X ( y , x ) 

ASSOCIATIVE 

i f  X(X(x,y),z)  =  X(x*X(y*z)) 

SPEC  Bool  earn 
SORTS 

Boo  1 

OPS 

True:  ->  Bool 

False:  •>  Bool 

Not :  Bool  ■>  Boo  1 

And:  Bool*3ool  *>  Bool 

AXIOMS 

Not(True)  =  False 
Not ( Not ( x ) )  =  x 
And ( T  rue  *  x )  -  x 

And(False*x)  =  False 
And  is  COMMUTATIVE 
And  is  ASSOCIATIVE 

SPEC  Natural 
SORTS 

Nat 

OPS 

0:  ->  Nat 
Next:  Nat  • >  Nat 


SPEC  Integer 

EXTEND  Boolean, 
Natural 

WITH 


SORTS 
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Int 

OPS 

0 :  ->  Int 
Next:  Int  *>  Int 
Neg:  Int  •>  Int 
Add:  Int, Int  ” >  Int 
Sub:  Int , Int  ->  Int 
Lte:  I nt  ,  In t  ->  Bool 
Abs:  Int  ->  Nat 


NOTATION 

-x  is  Neg ( x ) 
x+y  is  Add ( x , y ) 
x-y  is  Sub ( x , y ) 
x<=y  is  L  t  e  (  x  ,  y  ) 

AXIOMS 

Add  is  COMMUTATIVE,  ASSOCIATIVE 
Add ( x , 0 )  =  x 

Add ( x , Nex t ( y  )  )  =  Nex t C A dd ( x , y ) ) 
Neg ( 0 )  =  0 

Ne x t ( Ned ( Nex t ( x ) ) )  =  Neg(x) 

Add(x,Neg(x))  =  0 
Sub(x,y)  =  Add(x,Neg(y)  ) 

Lt  e ( x , x  )  =  T  rue 

Lte(x»y)  ->  L t e ( Ne x t ( x ) , y ) 

Lte(x»y)  =  Lt e ( Sub ( x , y ) , 0  ) 

END 

SPEC  Character 


SORTS 

Char 

OPS 

A  :  -> 

Char 

a :  •> 

Char 

0:  -> 

Char 

b:  -> 

Char 

•  •  • 

END 

SPEC  Ident i f i er 

EXTEND  Boolean  WITH 
SORTS 

Id 

OPS 

Register:  ->  Id 
Main:  ■*>  Id 
Disk:  ->  Id 
Disolay:  - >  Id 
Eqi d:  Id, Id  ->  Bool 
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AXIOMS 

Eq 1 d ( x , x )  =  True 

END 


SPEC  String 

PARAMETER 


EXTEND 

WITH 

SORTS 

OPS 


AXIOMS 


SORTS 

Elen 


Natural 


Str 

Null:  ->  Str 
Make:  Elern  ->  Str 
Cat:  St  r  *  St  r  ->  Str 
Len:  Str  ->  Nat 
Head:  Str  ->  Elen 
Tall:  Str  ->  Str 


LenCNul 1 )  =  Nat  zero, 

Len(Make(a) )  =  Nex t ( Na t z e ro ) 

Head(Make(a))  =  a 

Tall (Null  )  =  Null 

Tai 1 (Make (a) )  =  Nul 1 

Cat  Is  ASSOCIATIVE 

Cat(s»Null)  =  Cat(Nu11#s) 

Cat(s»Null)  =  s 

Head ( Cat ( Make ( a ) , s )  =  a 

Tail(Cat(Make(a),s)  =  s 

LenCCat (Make(a) , s)  1  =  Next(Len(s)) 

Len (Cat ( s , Make ( a ) )  =  Next(Len(s)) 


END 


SPEC  Bi tstring 

St  r i ng ( Boo  1 ean ) 

where 

Elen  IS  Bool 

END 


SPEC  Chrstring 

String(Character) 


WHERE 


Elen  IS  Char 
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END 


SPEC  Data*-val  jes 


EXTEND 

Boolean 
Natural 
I n t  eqe r 
Character 
B  i  t  s  t  r i ng 
Chrstring 


WITH 

SORTS 

OPS 


V  a  1 

Errval:  •>  Val 


Va  1  *-t  o*-boo1  :  Val  ->  Bool 
Val  *-t  o*-nat :  Val  ->  Nat 
Valt’toHnt:  Val  ->  Int 
Va  1  *-t  o*-c  h  r  :  Val  •>  Chr 
Val  *-t  o*-b  1  t  st  r  :  Val  ->  Bitstr 
Val  t-to**chrst  r  J  Val  •>  Chrstr 

Boo  1  t  o*-v  a  1  :  Bool  •>  Val 
Net  **t  o**va  1  t  Nat  •>  Val 
I  n  t  t  o**va  1  s  Int  •>  Val 
Charval;  Char  ->  Val 
B  i  t  st  r*-t  o*-va  1  :  Bitstr  inq  ->  Val 
Chrst  r*-to*-val  :  Chrstring  ->  Val 


AXIOMS 

FOR  X  =  Boo  1 » Na t » In t , Ch ar , B i t s t r , Ch r s t r 

Va  1  *-t  o«"X  (  X«-t  o*"v  a  1  (  x  ) )  -  x 

X*-t  o«-va  1  (Va1«-to*-X(v))  =  v 

FOR  X,Y  =  Boo  1 , Na t ,  I n t , Ch a r , B i t s t r , Ch r s t r 
X  t=  Y  t 

X«-t  o*-  va  1  (  Va  1  <-t  o*-Y  (  v  )  )  =  Errval 


SPEC  Addresses 
EXTEND 

Identifier, 

Boolean 

WITH 

SORTS 

Addr 
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OPS 

Startaddr:  Id  *>  Addr 

Nextaddr:  Addr  ->  Addr 

Equal addr :  Addr»  Addr  •>  Bool 

AXIOMS 

Equaladdr  is  an  EQUIVALENCE 

Equa 1 addr ( S t a r t addr ( x ) »  S  t  a  r  t  add  r  C  y )  )  =  Equal  id(x»yN 

Equa 1  add r ( Ne x t a ddr ( x ) ,  Nextaddr(y))  s  Equa 1 addr ( x , y ) 

SPEC  Operators 

EXTEND 

Dat  a*-va  1  ues 

WITH 

SORTS 

Monoo  > 

B i noo • 

Re  1  oo 

OPS 

Boolnot;  •>  Monoo 

Boo  land:  •>  Binoo 

Nat  add :  ->  Binoo 

Intadd:  ->  Binoo 

Chrst  rcat :  ->  Bi noo 

Bitstrcat:  *>  Binoo 

Intgt:  ->  Reloo 

AXIOMS 

•  •  • 

ApolymonoD:-  Monoo* Val  ->  Val 

Apolybinoo:  B i noo * Va 1 * Va 1  ->  Val 

Appl yrel oo:  Re  1 oo * Va 1 , Va 1  ->  Val 

App 1 ymonoD C Boo  1  not * v )  = 

Bool  val  (Not  ( Val  «-t  o«-bool  (v))) 

Aoo 1 yb i pod ( Boo  1  and » v 1 » v2 )  = 

Boolval  (And(Val«-to«-bool  (vl)*Val*-to*-bool  (v2))) 

•  •  •  6  t  C  •  k. 

SPEC  Instructions 
EXTEND 

Ope  r a  t o  r  s 

WITH 
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SORTS 

I  ns  t  r 

OPS 

Monad:  Monoo, Addr ,  Addr  ->  Instr 
Binad:  B i noo , Add r , Add r , Addr  ->  Instr 
Mov:  Addr, Addr  “>  Instr 
Movi:  Addr/  Val  ->  Instr 
Jmo :  Addr  ->  Instr 

If:  Rel op, Addr , Addr , Addr  ->  Instr 

Push:  Addr,  Stk  ->  Instr 

Pod:  Addr,  Stk  ->  Instr 

Call:  Addr,  Stk  ->  Instr 

Ret:  Stk  ->  Instr 

Halt:  •>  Instr 

SPEC  Values 

EXTEND 

Data*-  values, 

Instructions 

WITH 

OPS 

Inst  r«-t  o*-va  1  :  Instr  •>  Val 
Va  1  ►t  o*"  i  ns  t  r  :  Val  ->  Instr 

AXIOMS 

Va  1  **t  o*-  i  ns  t  r  ( I  ns  t  r*t  o*"  v  a  1  ( i  ) )  =  i 
I  ns  t  r  «-t  o«-  va  1  (  Va  1  *•  t  o«-  i  n  s  t  r  (  v )  )  =  v 

FOR  X  =  Bool , Nat , Int ,Chr,Bi tst r,Chrst r 

I  ns  t  r  t-t  o*-  va  1  ( Va  1  «-t  o*-X  ( v  ) )  -  Errval 


SPEC  Machinestate 
EXTEND 

Val ues , 

Instructions 

WITH 

SORTS 

State 

OPS 

Ini t i al state:  ->  State 
Store:  V  a  1 , Addr , St  at e  ->  State 
Fetch:  Addr,  State  •>  Val 

AXIOMS 

Fe t ch ( a , I n i t i a  1 s t at e )  =  Errval 
Fe t c h ( a , S t o r e ( v , a , s ) )  =  v 
St o re ( Fet c h ( a , s ) , a , s )  =  s 

SPEC  Machine 


EXTEND 


Machi nestate 
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WITH 

OPS 

Program:  Addr/State  ->  State 
Execute:  Inst r» Addr* State  *>  State 

AXIOMS 

P  rog  r am ( a  r  s  )  = 

Execute(Val«-to*-instr(Fetch(a»s))ra»s) 

Ex ec ut e ( Mo v ( a  1 f a2 ) » a f s  )  = 

Program (Next (a) »  S  t  or e ( (Fetch(al *s)  »a2» s) ) 

Ex ec u t e ( Mov H a  1 / v ) » a / s  )  = 

Program(Hext (a)»3tore(v»alfS)) 

Ex  ecu t e ( Jmo ( a  1 ) / a / s )  = 

Program ( a  1 / s  ) 

Execut  e  ( I  f  (  r ,  a  1 1  a2 ,  b  )  /  a ,  s  )  =  Pr  ogram  ( (Cond  ( Va  1  «-t  o«-boo  1 
( Apol y rel oo( r ,  Fet ch ( a  1 ,  s ) , Fet  ch ( a2, s ) ) ) ,b, Nex t  C  a) ) ,  s ) 
Execute (Hal t f af s)  =  s 

E x ec u t e ( Mon ad ( m > a  1 » a2 ) / a t s ) )  =  Program (Nex t ( a ) > 

Store(ADolymonoo(m,Fetch(alfS))»a2»s)) 
Execute(Binad(b,al , a2,a3) ,a, s)  =  P rogr am ( Ne x t ( a ) , 
Store(Aoplvbino3(bfFetch(al»s)»Fetch(a2»s))»a3fS)) 
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